DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency

作者信息

UIUC和Microsoft

链接：[2408.00741] DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency

摘要

The rapid evolution and widespread adoption of generative large language models (LLMs) have made them a pivotal workload in various applications. Today, LLM inference clusters receive a large number of queries with strict Service Level Objectives (SLOs). To achieve the desired performance, these models execute on power-hungry GPUs causing the inference clusters to consume large amount of energy and, consequently, result in excessive carbon emissions【碳排放】. Fortunately, we find that there is a great opportunity to exploit the heterogeneity in inference compute properties【利用推理的异质性】 and fluctuations in inference workloads【和推理工作负载的波动】, to significantly improve energy-efficiency. However, such a diverse and dynamic environment creates a large search-space【挑战：多样和动态的环境，搜索空间很大】 where different system configurations (e.g., number of instances, model parallelism, and GPU frequency) translate into different energy-performance trade-offs. To address these challenges, we propose DynamoLLM, the first energy-management framework for LLM inference environments.【第一个针对LLM能源管理的系统】 DynamoLLM automatically and dynamically reconfigures the inference cluster to optimize for energy and cost of LLM serving under the service's performance SLOs【在满足SLO情况下，通过动态重新配置集群，实现energy成本的最优化】. We show that at a service-level, DynamoLLM conserves 53% energy and 38% operational carbon emissions, and reduces 61% cost to the customer, while meeting the latency SLOs.

一句话总结概括

第一个面向能源的大模型服务系统

Motivation

1. Heterogeneous Energy-Performance Profiles

LLM的heterogeneity：

  1. request的输入、输出长度不一
  2. 不同Model情况下compute properties不同
  3. 同一个Model情况下有不同的SLO需求

表一： 不同输入输出文本情况下的Wh

表二：不同负载情况下的Wh

表三：不同模型情况下的Wh

image-20250120095613909

Insight1：可能需要结合上述三个变量，才能得到最优的energy配置。

2. Dynamic LLM Inference Workloads

同样有三个信息：

  1. Request 长度的分布：
  2. Request 负载的波动：比如夜间和周末负荷低
  3. SLO和模型的多样性：

image-20250120195211579

一周的负载，Conversation普遍有更长的output和更短的input，说实话没看出来。

而应对不同的负载，系统需要将其划分为多个不同的类，从而实现能源的最优化。但分类也不能分太细，因为过多的分类可能会因为资源的碎片化带来负面作用。所以，笔者采用的方法是利用历史数据来分类，每个Pool都会和另外一个服务更长一点的Request的Pool Merge在一起。

Insight2：工作负载是高度动态的，某时刻的最优配置可能很快就变为次优配置，可能需要一个自动的、用户透明的配置选择。

3. Reconfiguration Overheads

  1. Instance的数量
  2. model的并行性
  3. GPU的频率

如果想要在一个新的Instance上使用LLM，开销是巨大的。

image-20250121210923695

如果想要修改模型的并行性，需要同步所涉及的gpu，从GPU中卸载部分的权重，再加载到新的GPU上，也是minute级别的。

如果想要修改GPU的频率，也会带来不可忽略的开销：调用操作系统、通过系统调用与GPU驱动程序通信、通过固件执行硬件交互。会带来50ms级别的开销。下图是重新设置的吞吐量，可以看到Switch会带来显著的吞吐量下降。

image-20250121211658420

Insight3：重新配置会带来显著的开销，需要考虑如何最小化这部分开销。

具体设计

根据四个特性来设计：

  1. energy-optimized and SLO-aware
  2. instance pools
  3. dynamically reconfiguring
  4. minimizing reconfiguration overheads

image-20250121212327183

  1. Cluster Manager
    1. 接收Request，预测其req类型，分发到对应的Pool
    2. 根据负载重新评估需要多少池和每个池需要多少instance
  2. Pool Manager
    1. 接收Cluster分配的Request请求，以最小化池能耗的方法分发实例的instance
    2. 定期检查是否要重新分割为更节能的并行化方法
  3. Instance Manager
    1. 将请求调度到inference engine
    2. 定期检查是否需要调整GPU频率

性能优化角度：

配置实例

  1. LLM Profile
    1. 输入
      1. 不同负载
      2. 不同文本长度下
      3. TP2，TP4，TP8
      4. GPU频率变化 800-1980MHz
    2. 输出
      1. 预期的能量消耗
      2. TTFT/TBT

选择配置

image-20250121224711355

多变量线性规划问题，N（多少个Instance），f（单个instance频率），L（单个instance的负载）。这里假设了每个instance工作量是一样的。

但这会遇到另外一个问题，这种算法搜索空间很大，开销很大，不能在细粒度的间隔（几秒钟内）来选择系统配置，DynamoLLM选择是一层一层来获取局部的最优解。

  1. Scale-out/in（比如每三十分钟）
    1. cluster manager
      1. 计算每个instance内支持目前负载所需要的最小node数目
      2. load predictor预测未来负载
      3. 假设所有实例都在高GPU频率下执行
      4. 分配（预测负载/节点最大负载 ）个node到该pool
    2. 处理碎片化：
      1. 每隔一段时间系统就将一部分负载转发给更大的一个池，所以只有最大那个池会被过度分配资源，从而减少了碎片化。
  2. Shard-up/down（比如每五分钟）
    1. pool manager
      1. 如何将分配的N个GPU从集群正确分割为模型指定的并行性
      2. 假设所有实例都在高GPU频率下执行
      3. 只控制并行性
    2. 记录Overhead
      1. 后面可以直接使用该历史数据
    3. 减少停机风险
      1. 一次只重新配置具有最高潜在收益的那部分子集，避免一下子太多机器都停机
  3. Scale-up/down（比如每五秒）
    1. instance manager
      1. 在给定的模型并行情况下微调GPU频率
      2. 先用性能profile来过滤掉一部分不符合的频率
      3. 再用energy profile来选择最优的配置

降低重新配置的overhead

  1. Scaling in/out

    1. 保存模型在本地
    2. start VMs from a snapshot with the entire state of the inference engine already initialized
    3. 提前预测负载，主动提前创建VMs

  2. Sharding up/down

    1. 图算法

      image-20250122113328718

    2. NVLink间接传输

    3. 在新instance部署的过程中，旧instance依然在同步地处理请求

  3. Scaling up/down

    1. 将nvidia-smi程序直接加载到内存中

针对请求异质性的有效调度

  1. 预测长度
  2. 容错处理
    1. 假如检测到某些instance请求在堆积（分配有问题）
      1. 提高GPU频率
      2. 分发负载到别的instance
      3. 拒绝用户该请求的服务

results matching ""

    No results matching ""